home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 4
/
QRZ Ham Radio Callsign Database - Volume 4.iso
/
digests
/
tcp
/
940112.txt
< prev
next >
Wrap
Internet Message Format
|
1994-11-13
|
8KB
Date: Tue, 7 Jun 94 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V94 #112
To: tcp-group-digest
TCP-Group Digest Tue, 7 Jun 94 Volume 94 : Issue 112
Today's Topics:
Lurker needs info
MSS and FTP throughput with JNOS/PI2 (2 msgs)
nos-bbs mail address hosed? (2 msgs)
TCP-Group Digest V94 #111
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Mon, 6 Jun 94 11:16:49 EDT
From: crompton@nadc.nadc.navy.mil (D. Crompton)
Subject: Lurker needs info
To: tcp-group@ucsd.edu, tsjwr@camelot.acf-lab.alaska.edu
At crompton.nadc.navy.mil in /pub/internet are some files that may help.
Doug
------------------------------
Date: Mon, 6 Jun 1994 13:36:30 -0800 (PDT)
From: Glenn Elmore <glenne@sr.hp.com>
Subject: MSS and FTP throughput with JNOS/PI2
To: tcp-group@ucsd.edu
Although I can't say that I really solved all the issues, I did
manage to get things working pretty well with the PI cards and radios
this weekend.
The original problem I was having with MSS seems to have been solved by
specifying MSS and window *before* the driver is attached to JNOS. The
user is offered the opportunity to change these settings at any time but changes
after the attach apparantly have no effect except to cause the indicated values
to be incorrect. Thanks to John Ackerman, AG9V, who clued me into this
characteristic of JNOS. It was in the docs too but I'd missed it.
Once I modified the autoexec to correctly initialize mss and win, both
at 1024 bytes, things ran pretty well. Approximate performance is as
follows:
----------------------------------------------------------------------------
| radio speed | MSS | Window | FTP | % ch. capacity| data storage |
| kbps | bytes | bytes |char/sec | | |
----------------------------------------------------------------------------
| 38.4 | 1024 | 1024 | 3450 | 72.5 | hard disk |
| | | | 3850 | 80.2 | RAM disk |
----------------------------------------------------------------------------
| 57.6 | 1024 | 1024 | 5300 | 73.6 | hard disk |
| | | | 5750 | 79.7 | RAM disk |
----------------------------------------------------------------------------
| 230.4 | 1024 | 1024 | 17600 | 61.1 | hard disk |
| | | | 18500 | 64.2 | RAM disk |
| | 1024 | 8192 | ~5000 | 17 | hard disk |
----------------------------------------------------------------------------
These are with TxDelay of 1 millisecond (PI minimum). But setting it to
2 ms only caused about a 1% decrease in throughput at 230.4 kbps.
These numbers apply equally to wire or radio connections, though at
230.4 kbps some positions of the whip antenna which is on the #2 radio
caused a few retries which dropped throughput drastically, down to 12000
kbps pretty easily. I suspect I have multipath or perhaps overload
related issues running with both systems as they are, local to the
garage at n6gn.
As can be seen, large TCP Windows seem to be bad news. I'm not sure
why. It's possible that DCD isn't working right, that I was running out
of interrupt buffers or that ACKs aren't coexisting with incoming data
somehow. This probably needs more investigation.
At 230.4 kbps performance now seems good enough that I'm not very
interested in spending a lot more time tuning things. I think it is
fair to say that the PI cards can do onboard RxClock recovery just fine
and that system performance is a pretty decent fraction of raw channel
capacity. When doing transfers to hard disk at this rate, the drive
access LED is pretty much a continuos blur. The 1.1 Megabytes of ZIPped
JNOS sources transfers in about a minute.
Now with the "more correct" JNOS configuration, a 50 mile, two hop,
38.4 kbps radio connection shows about 1100 char/sec throughput end-end.
Hopefully we'll be able to upgrade the X1J TNC2 which is presently the
middle node to a 386DX/PI-card and almost double this performance even
before increasing the radio speed.
Since the 230.4 kbps h/w changes have been made on all PI cards, we
should be able to turn the entire system speed up remotely once we
are ready.
Thanks to all who replied with suggestions. More work remains to done
with greater packet length and I still haven't gotten JNOS110D to do
better than about 5000 char/sec with an Ethernet card but the JNOS/PI2
combination seems to be performing pretty well now.
Glenn n6gn
------------------------------
Date: Mon, 6 Jun 1994 16:05:53 -0700
From: djc@intrepid.th.gov.bc.ca (Doug Collinge)
Subject: MSS and FTP throughput with JNOS/PI2
To: tcp-group@ucsd.edu
On Jun 6, 1:36pm, Glenn Elmore wrote:
} As can be seen, large TCP Windows seem to be bad news. I'm not sure
} why. It's possible that DCD isn't working right, that I was running out
} of interrupt buffers or that ACKs aren't coexisting with incoming data
} somehow. This probably needs more investigation.
I noticed this phenomenon at 56k some time ago. It never got to the top
of the stack of priorities so I never really looked into it - I just
figured NOS TCP was broken in some way and forgot about it.
} Thanks to all who replied with suggestions. More work remains to done
} with greater packet length and I still haven't gotten JNOS110D to do
} better than about 5000 char/sec with an Ethernet card but the JNOS/PI2
} combination seems to be performing pretty well now.
I worked with packets up to 8KB and it made a substantial improvement on
a very good channel. I'm not exactly sure why, since the decrease in
ACK traffic could not account for the improvement. Perhaps it was better
buffering or something.
--
Doug Collinge djc@intrepid.th.gov.bc.ca Emerging Technology
Ministry of Transportation and Highways, Province of British Columbia
"40-Plus Oldies: where the hits are as soft as your gut!" - E. Harris
------------------------------
Date: Mon, 6 Jun 94 17:01:15 EDT
From: crompton@nadc.nadc.navy.mil (D. Crompton)
Subject: nos-bbs mail address hosed?
To: brian@cyberpunk.ucsd.edu, tcp-group@UCSD.EDU
Brian -
Then can I assume that the MX procedure in NOS is broken? It appears
to use this left to right approach - I.E. xxx.xxx.xxx.na (anything .na)
gets a namibia mx record, or am I intepreting what you say wrong?
Doug
------------------------------
Date: Mon, 6 Jun 1994 14:33:37 -0700
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: nos-bbs mail address hosed?
To: crompton@nadc.nadc.navy.mil, tcp-group@ucsd.edu
If that's what NOS is doing, it's broken.
- Brian
------------------------------
Date: Mon, 06 Jun 1994 20:01:49 -0400 (EDT)
From: "Steve Dworkin, N2MDQ" <N2MDQ@delphi.com>
Subject: TCP-Group Digest V94 #111
To: TCP-Group@ucsd.edu
Brian:
Thanks for your reply. I am not looking for a judicial comment,
or even a judgement call, but rather how the system operates in terms
of the format for passing you information. In addition, we will have
to work out Bob's volunteerism locally. If there are any changes,
we will let you know. Tnx and 73.
Steve, N2MDQ
n2mdq@delphi.com
------------------------------
End of TCP-Group Digest V94 #112
******************************